Apache: Verschlüsselung und Webanwendungen einrichten

Eine SSL-verschlüsselte Website zu erstellen ist zwar kein Hexenwerk, aber weitaus komplizierter als man als Einsteiger glaubt. Wer noch keine Erfahrung damit hat, weiß meist nur, dass es aus der Sicht eines Clients relativ einfach ist, im Browser eine URL mit https:// statt mit http:// am Anfang einzutippen.

ZDNet zeigt am Beispiel von Debian und verwandten Distributionen wie Ubuntu und Linux Mint wie man in Apache eine SSL-Verschlüsselung einrichtet. Zu beachten ist, dass die Struktur der Apache-Config-Dateien in anderen Distributionen, etwa von Red Hat oder Suse, grundsätzlich anders ist. Diese Anleitung ist für Linux-Distributionen, die nicht auf Debian basieren, daher nur bedingt geeignet.

Ein wenig Erfahrung wird allerdings vorausgesetzt. Einsteigern, die noch nie eine Website mit Apache aufgesetzt haben, sei an dieser Stelle das ZDNet-Tutorial "Hosting auf dem Root-Server: So konfiguriert man Apache" empfohlen.

Um zu verstehen, wie eine SSL-Website grundsätzlich funktioniert, kommt man nicht ganz ohne Theoriewissen aus. SSL, das offiziell heute TLS heißt, bietet nicht nur eine einfache Verschlüsselung, sondern stellt auch über ein Zertifikat sicher, dass der Benutzer Man-in-the-Middle-Attacken erkennen kann.

Ohne Zertifikat kein SSL

Ein solches Zertifikat muss für jede SSL-Website im Webserver installiert werden. Man kann sich ein solches Zertifikat leicht selbst herstellen. Allerdings warnen alle gängigen Browser, wenn sie ein Zertifikat präsentiert bekommen, dass nicht von einer anerkannten Zertifizierungsfirma stammt. Diese Warnung kann man ignorieren und gleichzeitig festlegen, dass das Zertifikat von nun an immer akzeptiert werden soll.

Wer eine öffentliche Website betreibt, wird aber mit Akzeptanzproblem zu kämpfen haben, wenn unerfahrene Benutzer durch Sicherheitswarnungen irritiert werden. Es ist daher besser, sich ein Zertifikat von einem anerkannten Aussteller zu beschaffen, den alle Browser ohne Fehler akzeptieren. Zum Testen und Ausprobieren reicht auch ein selbst erstelltes Zertifikat.

Zertifikate sind in der Regel kostenpflichtig und werden nur für bestimmte Websites ausgestellt. Ist es auf www.example.com ausgestellt, führt es auf www.example.net zu einer Fehlermeldung. Abhilfe schafft ein sogenanntes Wildcard-Zertifikat, das aber teurer ist als ein Zertifikat für nur eine Website.

Ein Wildcard-Zertifikat ist beispielsweise auf die Domain *.example.com ausgestellt. Die Browser akzeptieren ein solches Zertifikat etwa für www1.example.com und www2.example.com. Allerdings erzielt man trotzdem oft nicht das gewünschte Ergebnis: Wer die Website www.example.com betreibt, will in der Regel, dass sie auch unter example.com erreichbar ist. example.com ist aber in der Wildcard nicht mit eingeschlossen. Wer alle DNS-Namen abdecken will, braucht immer zwei Zertifikate – eins für example.com und eins für *.example.com.

Zertifikate werden ferner auf eine Person oder eine Organisation (zum Beispiel ein Unternehmen) ausgestellt. Das soll sicherstellen, das die Website einer Bank tatsächlich von dieser Bank betrieben wird. Allerdings gibt es verschiedene Klassen. Klasse-1-Zertifikate werden nur auf natürliche Personen ausgestellt. Dazu findet faktisch keine Identitätsprüfung statt. Es reicht aus, dass die Kreditkarte erfolgreich belastet werden konnte.

Besonders sicher bezüglich der Authentifizierung des Besitzers sind EV-Zertifikate (Extended Validation). Sie werden nur nach einer rigorosen Identitätsprüfung, etwa Meldebescheinigung oder Handelsregisterauszug und Nachweis der Vertretungsbefugnis ausgegeben. Sie sind entsprechend teuer und der bürokratische Aufwand für ihre Beschaffung ist hoch.

In der Praxis zeigt sich, dass Besucher einer Website meist wenig über Zertifikate wissen. Wenn der Browser keinen Fehler meldet, fahren die Nutzer fort. Daher reicht in der Regel ein Class-1-Zertifikat. Die meisten Anbieter verlangen dafür 10 bis 30 Euro. Die Firma StartSSL bietet sie sogar kostenlos an. Zertifikate von StartSSL werden von allen gängigen Browsern akzeptiert.

Nur eine SSL-Website pro IP-Adresse

Während man beliebig viele unverschlüsselte Websites auf einem Server mit nur einer IP-Adresse betreiben kann, ist das bei SSL-Websites nur bedingt möglich. In der Praxis wird man meist darauf verzichten.

SSL beziehungsweise TLS ist ein Tunnel-Mechanismus, der grundsätzlich auf jedes TCP-basierende Protokoll angewandt werden kann. Da pro Website andere Parameter existieren können, etwa welche Verschlüsselungsalgorithmen und -stärken erlaubt sind, muss der SSL-Tunnel in einer bereits existierenden Sitzung gegebenenfalls neu ausgehandelt werden. Das ist in alten SSL-Implementierungen nicht gegeben.

In der Praxis bedeutet das, dass User mit Windows XP und Internet Explorer (unabhängig von der Version) das neue Protokoll nicht nutzen können. Windows bietet SSL als Kerneldienst an, der von Internet Explorer genutzt wird. SSL-Neuaushandlung ist erst ab Windows Vista implementiert.

Alle anderen Browser implementieren SSL selbst. Wer etwa eine halbwegs aktuelle Version von Firefox, Chrome, Safari oder Opera einsetzt, hat keine Probleme mit der SSL-Neuaushandlung, egal auf welchem Betriebssystem.

Da viele Nutzer aber noch Windows XP und Internet Explorer verwenden, kann man Betreibern von öffentlichen Websites nicht empfehlen, mehrere SSL-Websites auf nur einer IP-Adresse zu betreiben. Besser ist es, bei seinem Hoster weitere IP-Adressen zu beantragen, was mit Kosten verbunden sein kann.

Eine ungeliebte Hilfskonstruktion ist es, SSL-Websites nicht nur auf dem Standard-Port 443 zu betreiben, sondern auch auf anderen Ports, etwa 8443. Eine Website, die auf diesem Port betrieben wird, hätte dann allerdings eine URL wie https://www.example.com:8443, was meist nicht erwünscht ist.

Aufsetzen einer SSL-Website in der Praxis

Als erstes überprüft man die Datei /etc/apache2/ports.conf. Um Kommentare bereinigt sollte sie wie folgt aussehen:

Apache kann SSL-Verbindungen entweder mittels GnuTLS oder mittels OpenSSL realisieren. Generell empfiehlt sich OpenSSL, da es mehr Features hat. Anschließend muss das SSL-Modul aktiviert werden. Das geht mit der Befehlsfolge

a2enmod ssl
apache2ctl configtest
apache2ctl graceful

Wer nicht als root angemeldet ist, muss jedem Befehl noch das Wort sudo voranstellen oder sich einmalig mit sudo -s Rootrechte verschaffen. Der Befehl apache2ctl configtest ist optional und bietet die Möglichkeit, die gesamte Konfiguration auf Syntaxfehler zu untersuchen. Vor der Aktivierung einer neuen Konfiguration mit apache2ctl graceful sollte er routinemäßig verwendet werden. Meldet er einen Fehler, müssen die geänderten Config-Dateien noch einmal überprüft werden.

Der Apache-Server ist jetzt grundsätzlich bereit, SSL-Verbindungen zu handhaben. Als nächstes muss eine SSL-Website konfiguriert werden. Wer bereits eine unverschlüsselte Website hat und diese auch per SSL anbieten möchte, muss die Konfigurationsdatei, beispielsweise /etc/apache2/sites-available/default kopieren und etwas abändern. Als Name empfiehlt sich etwa /etc/apache2/sites-available/default-ssl.

Angenommen, die Datei /etc/apache2/sites-available/default sieht wie folgt aus:

Um dieselbe Website zusätzlich SSL-verschlüsselt anzubieten, erstellt man die folgende Datei /etc/apache2/sites-available/default-ssl:

Neu sind die Anweisungen <IfModule> und </IfModule> in der ersten und der letzten Zeile. Sie stellen sicher, dass die Website nur gestartet wird, wenn das SSL-Modul von Apache korrekt geladen ist. Das <VirtualHost>-Statement wurde so abgeändert, dass es auf den HTTPS-Port 443 reagiert.

Die Befehle ab SSLEngine beschäftigen sich mit SSL und den Zertifikaten. Damit SSL prinzipiell funktioniert, müssen mindestens das Zertifikat und der dazugehörige private Schlüssel in den Anweisungen SSLCertificateFile und SSLCertificateKeyFile spezifiziert werden. Das Demo-Zertifikat /etc/ssl/certs/ssl-cert-snakeoil.pem und der zugehörige Schlüssel /etc/ssl/private/ssl-cert-snakeoil.key sind in jeder Debian-Distribution bereits vorinstalliert, so dass man sofort mit SSL starten kann.

Die Statements SSLCertificateChainFile und SSLCACertificateFile sind auskommentiert. Man benötigt sie meist, wenn man sich ein Zertifikat von einer anerkannten Firma besorgt. Ob, und welche der beiden Statements erforderlich sind, erfährt man vom Aussteller. Wer sich etwa ein kostenloses Class-1-Zertifikat von StartSSL besorgt, erfährt in der dortigen Anleitung, welche Dateien genau wie eingetragen werden müssen. Sobald man ein offizielles Zertifikat installiert hat, ist unbedingt darauf zu achten, dass die Schlüsseldatei, die hinter der Anweisung SSLCertificateKeyFile steht, immer geheim gehalten wird. Sobald sie in fremde Hände gelangt, muss das Zertifikat beim Aussteller als gestohlen gemeldet werden.

Zum Schluss kommt man nicht umhin, Probleme mit Microsofts Internet Explorer zu lösen. Die Browsermatch-Anweisungen sorgen dafür, dass Internet Explorer mit Apache-SSL-Websites zurechtkommt.

Wenn die Config-Datei erstellt ist, aktiviert man die neue SSL-Site und lädt die Apache-Konfiguration neu mit den Befehlen

a2ensite default-ssl
apache2ctl configtest
apache2ctl graceful

Im Browser sollte zunächst folgendes Bild erscheinen, wenn man die Website erstmalig aufruft und das Demo-Zertifikat verwendet.

Screenshot: ZDNet

Um die Website zu sehen, ignoriert man die Warnung und fährt. Je nach verwendetem Browser (hier Google Chrome) variiert die Warnung. Auch einige Antiviren-Programme melden sich mit einer zusätzlichen Warnung, meist aber nur, wenn man den Internet Explorer verwendet.

In der gezeigten Konfiguration wird dem Benutzer die Wahl gelassen, ob er die Website mit oder ohne Verschlüsselung benutzt. Wer erzwingen möchte, dass alle Benutzer eine SSL-Verbindung benutzen, kann das tun, indem die unverschlüsselte Website automatisch auf die verschlüsselte umleitet. Dazu verwendet man die folgende Konfiguration für /etc/apache2/sites-available/default.

Ein Nutzer, der in seinem Browser nur apache1.ZDNetLabs.Darktech.org/dir1/file2.htm eingibt (ohne Angabe eines Protokolls wie http://), wird automatisch auf https://apache1.ZDNetLabs.Darktech.org/dir1/file2.htm umgeleitet.